| r13 ➤ r14 |
| 51 | 사실 디도스라는 표현 자체는 틀린게 맞는데[* 정확한것은 낮고 느린 공격= 개요 == |
| 52 | [[엄지오(32기)]]의 디도스로 인곽위키가 장장 1일동안 멈추었던 사건이다. |
| 53 | 희진쌤이 노트북 닫아서 그런 것이라는 말은 거짓이다. |
| 54 | |
| 55 | == 원인 == |
| 56 | |
| 57 | == 결과 == |
| 58 | [[엄지오(32기)]]는 영구 밴을 '''또''' 먹을 예정이다. |
| 59 | |
| 60 | ==[[엄지오(32기)]]의 반박== |
| 61 | > 애초에 내가 아침에 요청 보낸건 상관없고 내가 요청 끝냈을때 서버 멀쩡했음 |
| 62 | > 몇시간 후에 1면때 희진쌤이 실수로 정보실에 있는 서버컴 꺼서 꺼진거임 |
| 63 | > 증인: 김규원 김도훈 희진쌤 |
| 64 | [* '''하지만''' 그 다음 꺼진 것이 김준서랑 이도혜가 동시에 커밋하다가 충돌났다는 말은 반은 맞고 반은 틀리다. 당일 오후 7시에 바로 수정하여 커밋을 올리고 김준서의 노트북으로 잘 돌아갔으나 갑자기 김준서의 추가적인 최적화 안된 커밋으로 에러가 뜬 것이다.] |
| 65 | |
| 66 | ===기술적인 반박=== |
| 67 | 인곽위키의 조회수 증가 로직을 보면, 내가 그때 초당 1~2회 수준의 /api/v2/page_view 요청을 계속 보냈는데, 디도스라고 하는 것은 개쌉오바를 떠는거라고 볼 수 밖에 없음ㅇㅇ |
| 68 | 디도스는 말 그대로 서비스 거부를 일으킬 정도의 과도한 트래픽이나 분산된 요청을 뜻하는데, 애초에 디도스 할거면 초당 몇천개씩 보냈겠지 |
| 69 | 그리고 내가 보낸 요청은 애초에 일반적으로 문서 보는것처럼 전체 문서 페이지(/w/...)를 계속 새로고침하는 것도 아님. |
| 70 | 그냥 문서 페이지를 열면 서버는 먼저 문서 원문을 가져오고, 렌더링을 수행한 뒤, 마지막에 별도로 조회수 증가 API를 호출함. |
| 71 | 근거: route/view_w.py의 320행, route/view_w.py의 336행. 코드는 깃허브에서 알아서 보셈 ㅇ |
| 72 | 다시 말해 /w/... 전체 요청은 “문서 조회 + 렌더 + HTML 생성 + 조회수 증가”까지 모두 포함하고 있음. |
| 73 | |
| 74 | 근데 나는 /api/v2/page_view/... 를 직접 호출해서 그보다 훨씬 좁은 처리 경로만 이용했음. |
| 75 | 따라서 /api/v2/page_view 2 req/s를 /w/... 전체 페이지 2 req/s와 같은 무게로 보는 것도 오바임... |
| 76 | 그리고 애초에 1초에 2번 요청도 못받으면 그게 서버임?? |
| 77 | |
| 78 | 그리고 Python 레이어의 구현도 이를 뒷받침한다고 볼수있음ㅇ. 조회수 API는 Python에서 자체적으로 무거운 비즈니스 로직을 처리하는 것이 아니라, 문서명을 받아 내부 Go 프로세스로 전달하는 브리지 역할임. |
| 79 | 근거: route/go_api_w_page_view.py의 3행, route/tool/func.py의 150행. |
| 80 | 그러니까 이 경로는 구조적으로 내부 서비스에 넘겨서 카운트만 갱신하는 단순 경로라고 할 수 있음. |
| 81 | 내가 매 요청마다 권한 계산이나 대규모 데이터 가공을 수행같이 복잡한거 시킨것도 아니고 단순한 요청만 보냈는데 진짜 뭐가문제임?? |
| 82 | |
| 83 | 추가로 데이터베이스 부분도 함께 보자면, 인곽위키는 SQLite를 사용하지만, 초기화 시 WAL 모드를 설정함. 근거: route/tool/func.py의 258행, app.py의 130행. |
| 84 | 여기서 WAL은 Write-Ahead Logging의 약자인데 이게 뭐냐면 데이터를 곧바로 원본 파일에 덮어쓰는 대신 먼저 “변경 내역을 별도의 로그 파일에 기록한 뒤 나중에 반영하는 방식”인데 이 방식의 장점은 읽기와 쓰기가 동시에 일어날 때 충돌을 줄여 준다는 점임. 일반적인 SQLite 기본 모드보다 동시 접근에 더 유리해가지고, 반복 요청이 곧바로 치명적인 DB 장애로 이어지는 가능성을 낮춰 줌... |
| 85 | 물론 WAL이 모든 문제를 해결하는 것은 아니긴해도 인곽위키가 WAL을 쓰고있는데, 그리고 2 req/s 수준의 저속 요청 밖에 안보냈는데, 이것때문에 사이트 다운됐다고 하기엔 좀 양심이.. |
| 86 | 애초에 2 req/s로 한시간 반 정도밖에 안했음 |
| 87 | |
| 88 | 그리고 위키 스파게티 코드문제 한두번 터지는 것도 아니고 실검 로직 이상하대서 실검 띄워지는지 해본건데 |
| 89 | 갑자기 몇시간 후에 책임 나한테 돌리는거부터 어이가 없음 ㄹㅇ |
| 90 | |
| 91 | ===결론 및 요약=== |
| 92 | 내 탓 아님 밴이나 푸셈 |
| 93 | |
| 94 | 첫째, 내가 요청을 마쳤을 당시 서버는 정상 동작 중이었다. |
| 95 | 둘째, 요청량 자체도 디도스라고 부를 수준의 폭주성 트래픽과는 거리가 있었다. |
| 96 | 셋째, 희진쌤이 서버컴을 껐다. |
| 97 | |
| 98 | == [[엄지오(32기)]]의 주장에 대한 반박 == |
| 99 | 저거 일단 AI 써서 자기 무관하다고 한거 같은데, 절대 아님. |
| 100 | 사실 디도스라는 표현 자체는 틀린게 맞는데[* 정확한것은 낮고 느린 공격이며, 사실상 느리게 한다는것 빼고는 서버에 과부하를 주는 디도스와 다를바가 없다.] 결론적으로는 엄지오 때문에 일어난 일은 맞음. |
